In communication system networks, network management generally relates to configuration management, performance management and fault management. Configuration management mainly reflects configurations of various types of NEs and important parameters in the network, and provides data for performance management and fault function management. Network management usually adopts polling methods to collect states of the monitored NEs so as to completely and dynamically manage the configuration data of the NEs in the whole network as well as the devices controlling, status checking and setup of the NEs etc., and collects data (parameters and the set status) from each network unit in order to guarantee the accuracy and reasonability of configuration data in the whole network.
Configuration data of the NE reflects current working environment and the operating status of the NE, and can be configured and output through an interface. The EMSs, command line terminals in serial port or remotely TELNET users can all asynchronously or synchronously configure the parameters of the NE and monitor the configuration status of the NE in a real-time manner. These flexible configuration methods make it more difficult for the EMS to synchronize the configuration data with the NE and centrally monitor the NEs. When a single NE has large amounts of data to synchronize or an EMS has to monitor multiple NEs at the same time, if a polling manner is adopted each time for synchronization with each NE, there will be large amounts of data to be done and it will certainly take a long time with low efficiency; not only the performance of the NE and EMS are affected, but also the performance of the whole network, so the method can hardly satisfy the requirement of practical applications.
Actually, after the NE is put into operation, many configuration data will remain relatively stable and can be considered as static data, so the synchronization of the NE with the EMS needs infrequent updating, and even if necessary, it is only needed to update the single NE with configuration changes or the changed part of the configuration of the NE; it is not necessary to update all the NEs in the EMS management domain. Full update operation is only needed in some special cases, such as: the EMS is initially utilized, the EMS has been disconnected from the NE for more than 1 day, configuration lost due to the EMS being restarted, the NE is restarted etc. Therefore, a mechanism should be provided for the EMS to synchronize configuration content with NEs, thereby reducing unnecessary synchronization operations of configuration data and improve network management efficiency.
To solve the above-mentioned problems, two solutions are usually adopted in the prior art:
(1) Providing a row identifier to report how many rows that a configuration table contains.
The configuration parameters of the NE are divided into several independent tables and each one has some properties. Each table is the smallest unit, a row identifier is provided for it, and its value represents the number of rows in the table, so that the configuration changes can be obtained by querying the row identifier.
(2) Providing an identifier of time stamp to report configuration changing time.
The configuration parameters of the NE are divided into some independent tables and each one has several properties. Each table is the smallest unit, a time stamp identifier is provided for it, and its value represents the time when the configuration changes, so that the configuration changes can be obtained by querying the time stamp identifier.
The above-mentioned technical schemes are complicated in implementation, and with poor operability and cannot actually solve the synchronization problem of configuration change.
If the first method is adopted, as there are more than one configuration items, the row identifier cannot fully reflect the configuration changes, for instance: if one row of data is added to the table while another one is deleted from the same table, the row identifier will not change; if no rows of the table is added to or deleted from the table but some configuration items are changed, the row identifier will not change, either.
If the second method is adopted, the same disadvantages still exist:
(A) The synchronization efficiency is not improved while the implementation difficulty is raised. It is too detailed that a configuration changing time is provided for each row of the table, if the EMS wants to know the configuration change of each NE, it must firstly read each time stamp of each table. The method is completely the same as the full synchronization, the only difference is whether to read one data or multiple data, if the NE configuration is changed, it even needs an additional step of pre-inquiry than the full synchronization, so the synchronization efficiency is not increased much and is even poorer in many practical applications.
(B) The EMS can not judge which NE the configuration belongs to. No matter operating on what terminal, time is needed from sending a configuration command to actually executing the command by the NE and then to responding the operation result by the NE, and the time is not a fixed value, so the time value cannot reflect which NE has changed the configuration. Thus the configuration changing value cannot be the condition of starting the synchronization operation.